|
|
|
|
|
|
|
Figure 7.1.
The benefit of reusability versus time. |
|
|
|
|
|
|
|
|
Note
Incorporating third-party controls and components early on involves cost and little reuse. Plan on little benefit over the first few months and possibly the first year or two. In time, reuse of the control will increase the return on investment substantiallyalso, incrementally, as increased technology, competition, and upgrades of the controls reduce the increase of returns on investment. |
|
|
|
|
|
|
|
|
|
Documenting Use Cases and Scenarios for Using Third-Party Controls |
|
|
|
|
|
|
|
|
As mentioned earlier, you have to define architecture for your application that includes a role to be fulfilled by any third-party control you plan to acquire and implement. Use cases will imply major subsystems within your application. Scenarios, with their corresponding sequence diagrams, will describe the roles that need to be performed by certain subsystems in the application. Assuming for a moment that you don't hire an evaluation committee, you need to evaluate and specify the role the control is to perform by |
|
|
|
|
|
|
|
|
Accepting proposals from in-house developers |
|
|
|
|
|
|
|
|
Accepting proposals from third-party vendors directly |
|
|
|
|
|
|
|
|
Measuring use cases against proposals |
|
|
|
|
|
|
|
|
Accepting Proposals from In-House Developers |
|
|
|
|
|
|
|
|
Although typically pressed for time, you or your development staff will be the best initial point of contact when it comes to acquiring a third-party control. Generally, a developer will have used a control in the past to solve a similar problem being undertaken by the current project. Thus, that developer should create a brief proposal listing the pros and cons of using that control and describing how it helped solve the problem. This proposal need not be formal or any longer than one page. |
|
|
|
|
|
